Many different types of products are utilized to provide security protections in information processing systems. For example, conventional products can detect the occurrence of security-related events such as firewalls being accessed, customer data being sent outside of a company, malware files being downloaded, or security policy violations. A given such product is typically implemented in software and configured to alert a security operator or other user upon detection of particular events. The number of reported events can be very large in practice. However, the user generally has only finite resources available for further investigation of the reported events.
Accordingly, when security-related events are reported to the user, the user must select which ones to spend time investigating. The user will then focus on the selected events in order to determine the appropriate remediation actions, if any, that should be taken in response to those events.
In conventional practice, the decision on which events to select for further investigation may be based primarily on static rules that are hard-coded into the product and provide the user with an indication of a perceived threat associated with the event. For example, the product may specify a severity level for each detected event, from a range of levels such as low, medium, high and critical severity levels.
This static rules approach to determining the severity of a security-related event has a number of significant drawbacks. For example, such an approach is unable to adapt to a changing system environment, and can lead to incorrect evaluations for environments that are different than expected. As a result, the user may require that a custom fix be made to the product, which increases its cost and complexity. In addition, the static rules approach does not take sufficient account of information regarding the particular manner in which the product is implemented and utilized by the user.